1. Field of the Invention
The present invention relates to migrating transport connections in a communications network, and, more particularly, to migration of existing sessions across addresses in a packet network.
2. Description of the Related Art
With growth and proliferation of mobile and wireless computing devices (mobile devices) that access the Internet, an infrastructure to support seamless roaming across internet protocol (IP) subnetworks (subnets) is required. Many users employ a dynamic host configuration protocol (DHCP) to obtain an IP address for connectivity, but employing DHCP only provides portability and does not provide relative transparency for seamless roaming. Every move across an IP subnet by a mobile device requires first releasing the old IP address and then acquiring a new IP address, which results in the loss of transport (and higher-layer) connections.
Normal network communication between two entities includes specifying a unique endpoint identifier, such as an IP address, that does not change during the communication period. For example, a typical transmission control protocol (TCP) connection establishment procedure between two endpoints (e.g., hosts) begins with the applications using a socket application programming interface (API) packet. Each socket API is explicitly bound to a given 5-tuple comprising the following five elements. The first element is the “Protocol” element identifying the particular communication protocol for the packet. The second element is the “Source IP address” element identifying the IP address of the source node originating the packet. The third element is the “Source Transport Port” element indicating the port of the source node originating the packet. The fourth element is the “Destination IP Address” element identifying the IP address of the destination node to receive the packet. The fifth element is the “Destination Transport Port” element indicating the port of the destination node receiving the packet. Any changes to any of these 5-tuple elements during a session will cause a session failure and typically initiates connection re-establishment.
Given the 5-tuple structure, the following outlines establishment and maintenance of a connection in current TCP-compliant packet networks. A TCP engine's connection establishment procedure involves a sequence of message exchanges between a client (first endpoint) and a server (second endpoint). The client begins by sending a SYN message to the server, and the client receives a SYN-ACK message from the server in response. The client responds back to the server with an ACK message in acknowledgment, and the connection between the client and the server is then open and fully functional. The TCP engine on both ends of the connection goes into the ESTABLISHED state with the state information being maintained in the TCP Control Block (TCB) within the operating system kernel. The TCP session is now uniquely identifiable in the network by the 5-tuple contained in the IP datagrams (packet header portions) traversing the network. From the application's and the operating system kernel's perspective, this session can be uniquely identified by the socket associated with this session. Any change to even one of the elements of the 5-tuple leads to session failure.
A TCP session failure occurs when TCP aborts the connection and closes the associated socket bindings. There are many reasons for the TCP to abort a connection, some of which include: 1) receiving a TCP RST (reset) packet from the remote end; 2) exceeding the number of retransmission attempts defined by the protocol; 3) too many unacknowledged “Keep-Alive” probes; 4) a request by the application; and 5) an abnormal external condition. These TCP reset conditions routinely occur in normal operation of a packet network, and may arise from changes to the interface IP address, extended periods of connectivity loss, host crashes/reboots, or similar contributions to TCP connection failure.
Since the application using the TCP transport session is bound to the socket with the original 5-tuple (with the old IP address), changing the IP address of the interface doesn't change the associated application socket binding. Any user data sent by the application to the kernel gets queued at the TCP layer as transport layer segments in TCP's send-queue (send-Q) because there is no valid output interface with the old IP address to send out the data on. TCP's retransmit mechanism keeps retrying to send this data out until a valid route/interface appears or the connection times itself out. If there is no reachability between the two end systems, the TCP state on either side continues to be (normally) in its previous state (e.g., both sides continue to be in ESTABLISHED state). If the IP address of the interface reverts back to its original address (thereby, the original 5-tuple), communication between the endpoint applications resumes, provided a route exists. However, if the IP address of the interface changes, any data packets received from the remote host get dropped at the IP layer since there is no valid interface to associate the data with. Both the local end and the far end time-out their respective connections depending on their TCP state.
This session establishment and maintenance process is restrictive and imposes limits on certain types of applications, such as user mobility or fault tolerant connections. Mobile IP of the prior art was developed to achieve host mobility by bypassing this restriction using routing techniques at the network layer. According to Mobile IP, for a node to change its point of attachment without losing its ability to communicate, currently one of the two following mechanisms must typically be employed: either 1) the node must change its IP address whenever it changes its point of attachment or 2) host-specific routes must be propagated throughout much of the Internet routing fabric. Both of these alternatives are often unacceptable. The first mechanism makes it impossible for a node to maintain transport and higher-layer connections when the node changes location. The second mechanism exhibits severe scaling problems, especially relevant considering the explosive growth in sales of notebook (mobile) computers.
Many techniques exist in the prior art that have been proposed to reduce host mobility and fault resiliency problems. These techniques can be classified into those providing a solution at the network layer (e.g., IP layer), the transport layer (e.g., TCP/UDP (User Datagram Protocol), or higher layers (e.g., the socket or application layer).
Mobile IP attempts to solve host mobility problems at the network layer by using a level of routing indirection or triangular routing of all packets from a correspondent host to a mobile node. This routing indirection is accomplished through the use of “Home Agents” and “Foreign Agents” that are proxies providing services to the mobile node. Although Mobile IP handles host mobility and reachability problems well, it does not handle transport connection failures (e.g., any changes to the transport endpoints leads to a session failure). Typically, applications depending on transport session connectivity need to be restarted and a new transport connection has to be established. Other disadvantages of Mobile IP include non-optimized triangular routing and extensive use of IP tunneling. Due to security reasons, service providers typically disallow tunneled packets. Further, due to the increased frequency of Denial-Of-Service (DOS) attacks, service providers use ingress filtering to block packets that spoof source addresses. Although the ingress filtering problem might be solved by using reverse tunneling, reverse tunneling leads to further sub-optimal use of networking resources and adds extra packet delays between the two endpoints.
Methods that attempt to solve the problem of end-to-end host mobility at the transport or higher layers typically either 1) split the connection into multiple segments, 2) modify a standard TCP implementation by adding new messages and states to the TCP state machine, or 3) trick the application into believing that the connection still exists while an attempt is made to re-establish the connection.
For example, MSOCKS (Mobile Sockets) uses a split-connection proxy for connection redirection. MSOCKS inserts a proxy in the communication path between the mobile node and its correspondent hosts and uses a TCP splice mechanism to break the connection into multiple segments and thus hide the mobility issues of the mobile node from the correspondent hosts. However, adding a communication path proxy might significantly degrade service.
Some techniques include introducing a library between the application and the socket API that preserves the illusion of a single, unbroken connection over successive connection instances. All these approaches require linking the application with their respective (specific) libraries. The illusion of an unbroken connection is obtained by tricking the application into believing that the transport session is still active, even though the transport session has closed. The intermediate library then attempts to re-establish the (new) transport connection and maps the new transport connection to the application using it. The implementation of, and operational difficulties involved with, such solutions include virtualizing mechanisms like I/O polling, asynchronous and non-blocking I/O processes, the need for timers and signal handlers, and the need for additional process control interfaces such as “wait”, “kill”, and “exec”.
Another technique provides a mechanism to achieve end-to-end host mobility by modifying the transport layer protocol and end applications. The modification adds new states and semantics to the TCP finite state machine and defines new TCP options to negotiate the migration of the connection. Other techniques exist that involve either changing the TCP header, packet format, protocol semantics, or adding additional headers in the packets. However, the disadvantage of these techniques is that the end-user applications have to be aware of the new feature to make use of it, implying required changes to those existing applications.